# Give you a talk for great good! #

## Introduction ##

Giving talks is hard - I know. It scared me a lot when I first started doing it;
getting up in front of an audience is intimidating *in itself*, and when it's
about something like computer science, doubly so. Your mind throws itself every
which way, trying to figure out where to begin when crafting the talk, and once
you add in the formality and complexity of computer science topics, it can be
quite scary.

However, it doesn't have to be this bad! By the time you've read this document,
you will be in a good place to start making your own talks, and delivering them
with *finesse*. While this won't guarantee your success, it will at least make
sure that you're well-equipped with the basics.

It is my desire in writing this that CSC members will contribute their wisdom,
experience and ideas to it. Giving talks is both an art *and* a science, and the
amount that could be said about it is huge. The goal of the CSC is for us to
share our knowledge and teach each other new things - this document being no
exception. Thus, if you have ideas to improve this document or something to add,
we welcome them.

## Your main idea ##

Before you even start with anything, you need to decide what the *main idea* of
your talk is. Given that this is computer science, it will usually be one of
these:

* An algorithm
* A data structure
* A theorem or proof
* A formalism (such as a method of analysis)

Note, that this is separate from the *context* or *use* of this main idea. These
usually serve to ground what you're talking about in some kind of real-world
problem or use case: however, the idea is *not* that real-world problem or use
case. It is certainly important to *have* a real-world problem or use case, but
it is used to **support** the idea, not replace it.

Any given real-world problem or use-case may well have **multiple** main ideas
behind it. Consider something like [PageRank][1]; even in a topic like this
(which is fairly narrow), there are several main ideas:

* Graphs in general
* Graph centrality
* The PageRank algorithm itself
* Ways in which the algorithm can be efficiently implemented
* Use of these methods in the context of distributed systems

*Any* of these could be the basis of a talk; however, only *one* of these should
be the basis for *your* talk! Ultimately, while you'd use (and make reference
to) PageRank no matter which of these main ideas you end up going with (because
otherwise, why do we care about it?), it will provide justification for the main
idea, which is what you're really talking about.

In some cases, you might already *begin* with a main idea. Perhaps you're
really fond of some kind of algorithm or data structure, or a method of
analysis, or some really interesting theorem in computer science. In that case,
great! However, in most cases, computer science is done in response to problems
or use cases from the real world; thus, you need to tease out **what** your main
problem is before you can begin.

Keep in mind, your problem doesn't have to be hard - the CSC is a diverse group
with regard to levels of knowledge and understanding of computer science, and
what might seem easy or obvious to someone might be revolutionary and amazing to
someone else. Thus, don't feel like you need to handle an idea that's very hard
to follow or complex: something simple can be just as good and interesting.

## Anatomy of a talk ##

Alright, you have your main idea, and you have a context to put it in. Now, it's
time to plan the talk. Remember, the audience will be hearing about this for the
first time, and to them, there are four questions that need answering, in that
order:

0. What (is this)?
1. So what (is so good about it)?
2. How and why (does it work)?
3. When and where (can and can't I use it)?

Your talk should thus follow the same progression. Essentially, you will have
four segments to the talk:

0. Motivation
1. Preliminaries
2. Description
4. Conclusion

### Motivation ###

In this part of the talk, it is your task to answer the 'what' and 'so what'
questions that are filling your audience's head before you begin. As a speaker,
the audience are willing to give you a shot to grab their attention and hold it
- you have to capitalize on that immediately. Describe the context or use case
that brought your main idea to prominence and required solving. Give reasons
for your audience to care about this idea. Get them *thirsting* to hear your
explanation of this brilliant new concept. Relate it to other areas - an idea
useful in one place likely has uses in many others. By the end of this section
of your talk, the audience should be *dying* to hear the details. 

### Preliminaries ###

Now that your audience have a context to put your main idea in, as well as a
reason to care, we need to prepare their minds to receive the idea. Computer
science, like any other science, is about precision and correctness, and in
order to ensure that there is no confusion or needless difficulty with our main
idea, we have to make sure that the audience are properly aware of anything they
will need to understand it.

While it is OK to talk in generalities and hand-wave when motivating your talk,
here, you have to get down to brass tacks. Use as much precision and formality
as you think you need, but don't avoid it if it's necessary - after all, we are
doing science here, and science needs to be precise. However, avoid defining or
explaining what you are not using - every definition, lemma or proof that your
audience will need to remember to understand your idea imposes a load on their
minds, and it's a load you want to keep as light as is reasonable.

### Description ###

Now comes the fun part - actually describing your main idea! Your audience is
now mentally prepared to receive it: give them what they want. Don't forget that
your main ideas may need proving; when you need proofs, keep them short and
clear. It is fine to refer to the results of others if doing otherwise would be
too long or difficult, but a talk about a topic is much stronger if you can
demonstrate your own ability to explain or reason, rather than just relying on
those of others.

### Conclusion ###

It is now time to 'rise' out of the detailed into the general again. Your big
idea has implications and limitations: in order to do good science, we have to
tip our hats to both of them. Call back to your motivation when doing both: very
few problems are *truly* ever 'solved', and there are likely many things you
could have spoken about, but ended up not, for reasons of time or clarity.
Mention important consequences, weaknesses of the methods, their relevance to
the world... anything that you think would make your audience want to keep
thinking on the main idea and its significance to them.

## Construction of the talk ##

Now that you've thought all those things through, put your talk together. This
will be a stop-start process, and might require several revisions; like any kind
of writing, it will take some time. Every time you write down more, you will see
a clearer picture of what you need to say and how you need to say it. Give it
the time and love it deserves.

After that, all that remains is to give the talk!

## Five do's ##

0. Rehearse your talk at least once, while timing yourself. You'll be amazed
   what this turns up.
1. Use slide overlays to focus audience attention. There is nothing more
   demotivating to a viewer than seeing a slide of text, most of which won't
   become relevant until much later.
2. Say stuff that *isn't* on your slides - that way, people have a reason to
   listen to you and not just read them!
3. Keep it simple! Computer science is already an area of deep and complex
   ideas; don't inadvertently make it harder than it needs to be. Remember the
   words of John Searle: ["If you can't say it clearly, you don't understand it
   yourself."][2]
4. Put yourself into your presentation. Think of yourself as an actor or other
   performer: the audience have come to hear *you* speak, not just to hear you
   *speak*.

## Five don't's ##

0. Use cues. They limit your connection to the audience, force you to 
   follow a 'script' instead of interacting naturally, and remove spontenaity
   from your talk. Try it - it's not as scary as it looks if you understand your
   topic and your slides.
1. Read what's on your slides. The slides are there to *support* what you're
   saying, not replace it. If we can get your entire talk by reading your
   slides, why even deliver it?
2. Over-use visual elements. Too many pictures are distracting, and sometimes,
   text gets the point across better (and your words even more so!).
3. Have too many slides. The more slides you include, the more your audience has
   to hold in their heads, and the more you will have to create and edit in the
   end. A good rule of thumb is **one slide per three minutes** (not including
   overlays).
4. Have slides with too much on them. Over-cluttering slides makes them hard to
   understand, and clouds the main idea. Remember: **on each slide, have one
   idea and up to four points**.

## Above all ##

Have fun! If you don't enjoy the topic or the talk, neither will your audience.
Be confident and prepared: from there, enjoy the ride.

## License ##

This document is released under a Creative Commons-Attribution-ShareAlike
license, version 4.0. See the LICENSE file for more details.

[1]: https://en.wikipedia.org/wiki/Pagerank
[2]: https://en.wikiquote.org/wiki/John_Searle#Intentionality:_An_Essay_in_the_Philosophy_of_Mind_.281983.29
